Internet Info 1994 March/Internet Info CD-ROM (Walnut Creek) (March 1994).iso/inet/ietf/acct/acct-minutes-91mar.txt

Text File | 1993-02-17 | 13.4 KB | 403 lines

CURRENT_MEETING_REPORT_



Reported by Cyndi Mills/BBN

ACCT Minutes

The Internet Accounting Working Group met on Tuesday, Wednesday, and
Thursday to:


   o Review the results of the February meeting in Boston.


      -  SNMP security and performance issues.
         SNMP seems a reasonable approach for transporting data, given a
         diskless meter, although FTP or other bulk file transfer
         mechanisms should also be allowed for meters which store
         accounting data on local disks.  Other transport mechanisms may
         be discussed later.

      -  Background Document.
         The background document can be released for general comment as
         an Internet Draft after the addition of PICTURES and
         explanations which illustrate how the accounting mechanism
         addresses a variety of scenarios.  It is anticipated that the
         Background Document will be expanded again later.

      -  Architecture Document.
         The existing architecture document can be released for general
         comment after revision and the addition of control parameters.
         Before it is released to the Internet Drafts area it will be
         posted to the Working Group mailing list for review.

      -  Meter Services and MIB.
         The February discussion of control parameters and reporting
         formats was summarized for continuation.


   o Discuss control parameters and reporting formats.


      -  A modified reporting format resulted for further discussion.

      -  A set of control functions was developed for further
         discussion.

      -  The notion of being able to account differently on different
         interfaces and make finer distinctions resulted in the further

                                   1






         development of a rule tree similar to those discussed in
         February.

      -  The ability to set the granularity of reporting in great detail
         through the use of a rule table was developed for further
         discussion.  The current scheme seems too complex to be readily
         implemented, but serves as a starting point for further work.
         One solution to bounding the problem is defining a short list
         of standard (static) rule tables, without allowing the more
         general case.


     A rough outline of the reporting format, control functions, rule
     tree, and rule table culled from the meeting notes and slides
     follows these minutes.

   o Additional notes about lengthy discussions.


      -  It was noted that the ADDRESS_ID described in the reporting
         format might be expanded to transport level and beyond (e.g.,
         application level), allowing for a more generalized accounting
         for any protocol stack, but that is beyond the charter of this
         Working Group.

      -  It was also noted that attributes might be included in the
         ADDRESS_ID rather than as a separate field of the FLOW_ID.

      -  Each packet shall be counted in ONE and ONLY ONE accounting
         record to avoid duplicate counts.  Accounting records may be
         combined by the collection host for additional aggregate
         traffic information.  This is a tentative response to the
         question Can a single packet be counted in multiple buckets of
         a single meter?

      -  Meters in routers have special properties, since they are privy
         to the routing decision.  Meters may be modelled as (a) one
         meter per interface (as a passive listener to the interface,
         not privy to the routing decision) or (b) one meter per router,
         aware of the both input and output interfaces for the packet.
         Passive listening devices must have a network address and
         possibly a separate connection to the network in order to be
         managed.  Should routers be modelled as having a single meter
         to avoid complicating management?


Action Items



Background             Add pictures to Internet Background and revise.

                                   2






                       If changes are not too substantial, post directly
                       to Internet Drafts.
Architecture           Revise Architecture Document to reflect control
                       requirements and reporting changes.  Post to
                       Working Group mailing list for (time-limited)
                       review before posting to Internet Drafts.
Meter Services         Make a stab at reducing the granularity control
                       (rule table) problem to a manageable level.
                       Further specify control parameters with the goal
                       of creating a MIB.
Co-ordinate            Coordinate with Remote LAN MIB and Operational
                       Statistics Working Goups since they may be
                       tackling similar problems of granularity control.



REPORTING FORMAT (notes from discussion, not a precision
representation):


Accounting Record ::=[ Meter ID and Unique Address provided by SNMP ]
   Start Time TIMESTAMP, [ optional ?  ]
   End Time TIMESTAMP, [ should be current time ?  ]
   Rule_Table ID? [ something might be needed here ...]
   SEQUENCE OF FLOW_RECORD. [ number of records, followed by records ]

FLOW_RECORD::=
   Flow FLOW_ID,
   Values VALUES.

FLOW_ID::=
   [0] Source ADDRESS_ID [ must have source or destination ]
   [1] Destination ADDRESS_ID or both ]
   [2] Subscriber_ID ADDRESS_ID [ optional ]
   [ Attributes not defined yet ]

VALUES::= [ rolling counters ]
   Fragments_Sent COUNT,
   Fragments_Rcvd COUNT, [ packets in the reverse direction are counted
                          here to avoid maintaining two accounting
                          records for a communicating pair - should'nt
                          this be optional for source or destination
                          only flow ids?  ]
   Bytes_Sent COUNT,
   Bytes_Rcvd COUNT, [ byte count of reverse flow ]
   First_Time TIMESTAMP, [ time first packet in flow seen if different
                          from meter start time ]
   Last_Time TIMESTAMP. [ time last packet in flow seen if different
                          from meter stop time ]


                                   3






ADDRESS_ID::= [ some fields may be null, i.e., don't care ]
   [1] INTERFACE_INDEX INTEGER, [ as defined by SNMP ]
   [2] LINK LEVEL ADDRESS NETWORK_ADDRESS,
   [3] INTERNET ADDRESS NETWORK_ADDRESS,
   [0] STRING OF OCTETS. [ anything else used as unique ID ].

NETWORK_ADDRESS ::=
   Choice of {
            [1] IP ADDRESS. (TCP/IP)
            [2] NSAP ADDRESS. (OSI) variable length.
            [n] X.25 Address (CCITT)
            [m] MAC (LLC)
            [x] STRING OF OCTETS. (any other arbitrary address) }

COUNT::=
   Extensible_Integer SEQUENCE OF OCTETS.



TIMESTAMP ::= [ defined by SNMP already, either absolute time or
ticks/seconds/since meter boot time ]

CONTROL PARAMETERS (notes under discussion):

Meter to Management:  (traps)

DECLARE DATA LOSS Trap to let manager know that accounting data is being
lost.

DECLARE HIGH WATER Trap to request that manager increase polling
interval.  (Used when number of flows increases.)

DECLARE FLOOD/FLUSH Trap dumping the flow records currently being
monitored by the meter.  (Lower priority first?)

Management to meter:  (polls and control)

SET HIGH WATER MARK A the meter when to send a trap indicating that the
management station should increase the polling interval.

SET FLOOD MARK A how full the table SHOULD be before the meter considers
panicking and dumping the contents of the meter to the management
station in raw (SNMP OPAQUE) form.

SET FLOW TERMINATION PARAMETERS The meter should have the good sense in
situations where lack of resources may cause data loss to purge flow

                                   4






records from its tables which (a) have already been reported and show no
activity since the last report (b) oldest flows or (c) flows with the
smallest number of unreported packets

- TIMEOUT The time in seconds since last packet seen (and last report)
after which the flow may be terminated.

- MAX LIFETIME Guidelines for the maximum lifetime of a flow.  (Not
mandatory, but the meter should make an effort at reporting time to
purge flows that have had a lifetime greater than this value, even if it
results in the instantaneous creation of a new flow with identical
parameters.

SET FLOW PRIORITY [ REPORTING MASK] (mask is an 8-bit quantity) Tell
meter which flows are considered ``critical'' - i.e., in a crisis
situations which flows can least afford to lose data.  Reporting mask is
set by the RULES TABLE in the SET GRANULARITY operation.

REPORT [ REPORTING MASK (0 or default indicates report ALL)] Poll to
meter indicating that a normal report of indicated flows should be made
(i.e., any flow whose rule has indicated that it has a bit set which is
set in the mask.

SET GRANULARITY [ RULE TABLE ] see RULE TABLE

RULE TABLE: (Editorial comment from the Chair:  This is all a very large
pie in the sky and not to be sliced seriously yet.)

SEQUENCE OF NUMBERED RULES.


RULE::=
   Field FIELD_DESCRIPTOR.
   [ Operator OPERATOR_DESCRIPTOR. ]
   Mask.  MASK_DESCRIPTOR.
   LIST OF ACTION_PAIRS.

FIELD_DESCRIPTOR ::=
   Length INTEGER. (0 is permitted to indicate lack of interest.)
   CHOICE OF:
            NETWORK ADDRESS. (including arbitrary strings)
            RESULT (VALUE) OF PREVIOUS MASKING OPERATION>.



OPERATOR_DESCRIPTOR ::= The source of much discussion on overhead,

                                   5






complexity, and feasibility.  Is anding and testing for equality to the
mask good enough or do we need to define a set of allowed operations?

MASK_DESCRIPTOR: A MASK of a length less than or equal to the field.
(Otherwise there is no match.  1's set in the mask indicate bits which
are of interest.  Actually, is is defined to be other identical to the
field_descriptor.  (LENGTH followed by RESULT or NETWORKADDRESS.)

ACTION_PAIR. VALUE or RANGE OF VALUES. If the results of the masking
operation fit this value or range of values, perform the following
actions.


Choice of:
            CONDENSE (FLAGS, FIELD_DESCRIPTOR, [SUBSCRIBER_ID])
            EXPAND (FLAGS, FIELD_DESCRIPTOR, {SUBSCRIBER_ID])
            IGNORE.
GO TO RULE NUMBER X.



CONDENSE indicates that the flow-record should use the designated FIELD
as the source or destination address (or attribute) in the FLOW-ID,
along with the designated SUBSCRIBER_ID (also a FIELD_DESCRIPTOR).
(Condense implies that all packets parsing to this point will be counted
in a single bucket.)

EXPAND is just like condense, except the the FIELD_DESCRIPTOR indicates
that the packets which parse to this point should be placed in multiple
flows with source or destination address (or attribute) as designated by
the the FIELD_DESCRIPTOR.

IGNORE indicates that we don't count this type of packet at all.

USE RULE NUMBER N indicates (theoretically) that the RESULT OF PREVIOUS
MASKING OPERATION is set to the result of the FIELD VALUE  &  (anded
with) the mask value, and the nth rule of the RULE TABLE is invoked
next.  This concept is disturbing because it allows for spaghetti tables
that dont make sense.  At this point a rule compiler front end becomes
necessary...<sigh>


NETWORK_ADDRESS ::= [this should follow reporting format]
   Choice of {
            [0] IP ADDRESS. (TCP/IP)
            [1] NSAP ADDRESS. (OSI) variable length.
            [n] X.25 Address (CCITT)

                                   6






            [m] MAC (LLC)
            [x] STRING OF OCTETS. (any other arbitrary identifier)}



Notes on Rules

Note that each packet can only by counted within ONE FLOW, so that if
all possible flows are added, the number should equal the total number
of packets processed.

If there are multiple ways a packet should be processed, the rules
should deposit enough information in the flow record (i.e.  flow-id) so
that the packet can be POST-PROCESSED to be counted in multiple billing
categories.

The RESULT field preceding the root of the tree is considered to be a
zero length field.

All rule tables must in fact map into non-looping binary trees, or we
won't be responsible for the result (To save space sub-trees may be
shared by different branches and recursion may be used, as long as it
can be shown that no infinite loops can occur Caveat emptor and all
that.).  When address tests are used (field = address type), recommend
performing tests on the interface number first, the link level address
second, the network address third, and the attributes (if any are
defined later) last.  Within an address type, test the source address
first and the destination address last.

Attendees

Sean Donelan             [e-mail]
Martin Dubetz            [e-mail]
Gary Ellis               [e-mail]
Charles Fineberg         [e-mail]
Dave Geurs               [e-mail]
Keith Hacke              [e-mail]
Donald Hirsh             [e-mail]
Cyndi Mills              [e-mail]
Agnes Moran
Chris Myers              [e-mail]
Kary Robertson           [e-mail]
Gregory Ruth             [e-mail]
George Sanderson         [e-mail]
Jonathan Saperia         [e-mail]
Anil Singhal
Kaj Tesink               [e-mail]
Paul Tsuchiya            [e-mail]

                                   7






Sudhanshu Verma          [e-mail]
Steve Witten



                                   8